分布式存储技术在应用中经常遭遇的11个问题 | 运维进阶
分布式存储解决方案因其灵活性、敏捷性、自动化、高成本效率、高度可拓展性等关键优势，近年来愈发受到业界关注。为了帮助大家解决在分布式存储，尤其是Ceph应用方面遇到的难点问题，社区日前组织了社区专家在线答疑活动，力求为大家答疑解惑。以下是社会会员提出的11个常遇到的典型问题。
1、分布式存储当前主要的应用场景有哪些？
@Garyy：
简单来说，就是存储设备分布在不同的地理位置，数据就近存储， 将数据分散在多个存储节点上，各个节点通过网络相连，对这些节点的资源进行统一的管理，从而大大缓解带宽压力，同时也解决了传统的本地文件系统在文件大小、文件数量等方面的限制。对于分布式存储，应用场景就很多了，如果你有以下需求：数据量大、高吞吐量、高性能、高扩展，那就推荐分布式存储。主要的应用场景：
1）块存储
类似传统存储IP San形式提供iSCSI接口，作为 虚拟化后端存储，
2）对象存储
视频，音频，图片类的存储，归档存储等，例如保险行业的“双录”系统，电子保单系统
3）文件存储
作为NFS，GPFS之类集群文件系统的替代品
@李静：
1、分布式块存储：
（1）云平台，私有云建设，分布式存储非常适合云平台的场景，传统集中式存储，一般都是标准iscsi协议挂载卷到openstack端，每个lun都需要单独挂载。配置MPIO等。而分布式存储是通过rbd协议挂载存储池给OpenStack，OpenStack端直接在存储里划分和创建卷，调用快照等高级功能，分布式存储和OpenStack是天生适配，更加合适OpenStack的私有云的发展。
（2）容器场景：2018年12月发布Kubernetes 1.13版本，用于容器编排引擎的标准存储接口container storage interface（CSI）已普遍可用。在这些产品中，容器本地数据服务的需求对于支持微服务结构变得非常重要，这些需求包括硬件不可知性、API驱动、基于分布式架构，能够支持边缘、核心或公共云部署等。超过 70% 的容器应用需要有状态数据持久化保存，SDS可以解决：需要敏捷的数据迁移、从多个应用容器同时访问数据的需求。所以容器场景的弹性灵活的需求也是非常适合分布式存储。
2、分布式文件存储：分布式文件适合大容量文件存储场景，横向扩展灵活，性能优于双控存储，例如非线编，共享NAS，高性能计算等等都非常适合，文件存储也是现阶段三种存储中市场使用最高的，但有些也在慢慢转对象存储，对象存储接口协议在逐步开发中，会有一个过渡阶段。
3、分布式对象存储：海量小文件需求，检索需求，大数据方向，金融的影像平台，有互联网传输需求，和公有云整合，企业高校的网盘，监控等等非结构化场景都适合，包括一些医疗的PACS也在逐步过渡到对象存储，未来最有爆发潜力的存储。
文件和对象都针对的非结构化场景，文件往对象转是大势所趋，在于对象S3接口的逐步推广，对象存储支持文件和对象互操作（文件协议写入，对象方式读出，反之亦然）也是顺应市场需求的产物。
@qsg0720：
金融行业：影像系统、档案系统、容器、私有云、备份
医疗行业：超融合、PACS影像存储
安防行业：监控集中存储、智能安防
教育行业：私有云、校园网盘
@潇洒D鱼：
除了 OLTP 单一业务极限IOPS需求，和极低时延（微秒），大部分业务场景都可以通过SDS 满足，金融领域的开发测试，容器云，电子影像，双录，广电领域的媒资，CDN，等等，都是当前SDS能够应对的场景，简单来讲，SDS本身是分布式架构，通过 Scale Up 和 Scale Out 对标准化服务器和网络的排列组合，可以获得业务希望获得的存储能力。
2、一套分布式存储节点规模在多少台合适？
@Hongke：
开个玩笑：抛开需求谈规模都是耍流氓——有实际的业务场景，量化的数据、流量规模才有测试结论。
1、如果是采购三方系统，对于CAP中的原则问题不是在我们的考虑范围，对于节点的配置涉及分布式系统的底层设计：数据同步（分片）、数据备份、master选举等。我们要做的就只有一点：看配置文件说明，遵循官方的节点配置公式。比较经典的节点配置公式：2/n + 1 （n为节点数），也就是集群中需要保证有半数以上的节点正常，这样可以保证master的半数投票获得率，数据备份也是同理。所以一般为达到机器的较高利用率节点数一般是：3、5、7、9...，视规模变化。
2、如果是自己设计一套分布系统，那考虑的问题不只是CAP原则还有，还有应用程序的可伸缩性，弹性和可管理性等。[微软Azure应用设计原则]感觉是不错的指导，建议看看，从分布式开发者角度出发了解分布式应用。
@Garyy：
分布式存储理论上的是没有节点上线的，可以无限扩展。但是，现实的情况是，超过500台节点后，整个集群的性能并不会随着节点的增加而增加，并且可能会出现集群数据重构导致的集群不稳定。
按照实际使用的情况，一般分布式集群存储容量超过70%的可用容量时，集群扩容会对集群性能产生巨大的影响。所以，一般做POC的时候，建议先把集群数据写满，然后擦除40%，在存有60%数据的集群上做POC，这个结果比较靠谱。
3、Ceph在海量小文件的环境下，稳定性和扩展性如何？
@Garyy：
海量小文件存储（简称LOSF，lots of small files）出现后，就一直是业界的难题，许多互联网公司也针对自己的具体场景研发了自己的存储方案，还有一些公司在现有开源项目基础上做针对性改造优化以满足业务存储需求；
一、通过对若干分布式存储系统的调研、测试与使用，与其它分布式系统相比，海量小文件存储更侧重于解决两个问题：
1、海量小文件的元数据信息组织与管理：对于百亿量级的数据，每个文件元信息按100B计算，元信息总数据量为1TB，远超过目前单机服务器内存大小；若使用本地持久化设备存储，须高效满足每次文件存取请求的元数据查询寻址(对于上层有cdn的业务场景，可能不存在明显的数据热点)，为了避免单点，还要有备用元数据节点；同时，单组元数据服务器也成为整个集群规模扩展的瓶颈；或者使用独立的存储集群存储管理元数据信息，当数据存储节点的状态发生变更时，应该及时通知相应元数据信息进行变更。
对此问题，各分布式存储系统主要采用以下对策：1）设计时就在文件名中包含了部分元数据信息，减小了元数据规模，元数据节点只负责管理粒度更大的分片结构信息；2）通过升级优化硬件，使用分布式元数据架构——多组(每组2台)IO性能更好的ssd服务器——存储集群的元数据信息，满足单次IO元数据查询的同时，也实现了元数据存储的扩展性；3）系统模块提供了图片逻辑卷到物理卷轴的映射存储与查询功能，通过cache集群来降低延时提高并发。
2、本地磁盘文件的存储与管理(本地存储引擎)：对于常见的Linux文件系统，读取一个文件通常需要三次磁盘IO(读取目录元数据到内存，把文件的inode节点装载到内存，最后读取实际的文件内容)；按目前主流2TB~4TB的sata盘，可存储2kw~4kw个100KB大小的文件，由于文件数太多，无法将所有目录及文件的inode信息缓存到内存，很难实现每个图片读取只需要一次磁盘IO的理想状态，而长尾现象使得热点缓存无明显效果；当请求寻址到具体的一块磁盘，如何减少文件存取的io次数，高效地响应请求(尤其是读)已成为必须解决的另一问题。
对此问题，有些系统采用了小文件合并存储+索引文件的优化方案，此方案有许多益处：a.合并后的合并大文件通常在64MB，甚至更大，单盘所存储的合并大文件数量远小于原小文件的数量，其inode等信息可以全部被cache到内存，减少了一次不必要的磁盘IO；b.索引文件通常数据量(通常只存储小文件所在的合并文件，及offset和size等关键信息)很小，可以全部加载到内存中，读取时先访问内存索引数据，再根据合并文件、offset和size访问实际文件数据，实现了一次磁盘IO的目的；c.单个小文件独立存储时，文件系统存储了其guid、属主、大小、创建日期、访问日期、访问权限及其它结构信息，有些信息可能不是业务所必需的，在合并存储时，可根据实际需要对文件元数据信息裁剪后在做合并，减少空间占用。除了合并方法外，还可以使用IO性能更好的SSD等设备，来实现高效响应本地io请求的目标。
当然，在合并存储优化方案中，删除或修改文件操作可能无法立即回收存储空间，对于存在大量删除修改的业务场景，需要再做相应的考量。
4、Ceph可以配置单副本吗？
【问题描述】采用Ceph搭建对象存储，用于小文件保存，几百TB的级别。但是大部分文件几乎不会被访问，有点儿像一个归档存储。如果使用两副本、三副本，硬盘数量太多了。如果在底层配置RAID组，把VD给Ceph，只做单副本，是否可行？
@吕作令：
不建议，建议硬盘直通进操作系统。做2-3副本保障数据安全。
1、如果在底层配置RAID组，把VD给Ceph，只做单副本相当于每个VD一个OSD。在VD出现问题后，由于数据是1副本，会数据丢失风险。
2、底层RAID在做数据恢复时，也会影响ceph集群异常
3、增加了集群运维难度，增大了集群风险点
@qsg0720：
建议采用纠删码（EC）来解决，可以得到70-85%的磁盘空间使用效率，不过性能比副本差一些。
@Garyy：
不建议配置单副本，为了保证系统的可用性和可靠性，必须采用两副本或者三副本或者在原场地养老的模式
5、Ceph一个 OSD 应该分配多少内存？
【问题描述】一个OSD应该分配多少内存？最近在测试Ceph集群，发现OSD占用的内存随着写入的数据越来越多，占用的内存也越来越多，最终都把系统内存完了。
root 31383 28.2 8.3 2593676 920976 ? Ssl Mar01 332:07 /usr/local/hstor/ceph_dir/bin/ceph-osd -i 42 --pid-file /var/run/ceph/osd.42.pid -c /usr/local/hstor/ceph_dir/etc/ceph/ceph.conf --cluster ceph
root 32534 21.2 8.4 2591672 936432 ? Ssl Mar01 249:22 /usr/local/hstor/ceph_dir/bin/ceph-osd -i 44 --pid-file /var/run/ceph/osd.44.pid -c /usr/local/hstor/ceph_dir/etc/ceph/ceph.conf --clust
@吕作令：
现在分配了多少内存出现问题了呢？Ceph 集群出现异常比如数据重平衡会大量使用内存， OSD 内存消耗通常与系统中每个守护进程的 PG 数有关。内存问题需要多注意，内存不够会导致 osd 重启，集群异常。ceph.com 也给出了推荐的 OSD 内存配置，可以参考一下，建议3-5GB吧。
OSDs (ceph-osd)
By default, OSDs that use the BlueStore backend require 3-5 GB of RAM. You can adjust the amount of memory the OSD consumes with the osd_memory_target configuration option when BlueStore is in use. When using the legacy FileStore backend, the operating system page cache is used for caching data, so no tuning is normally needed, and the OSD memory consumption is generally related to the number of PGs per daemon in the system.
@冰河_C：
按照官网给的建议，每TB数据分配1GB内存较为适中，当然如果内存越大越好，这样对于集群的数据均衡和高并发IO处理上，不会产生性能瓶颈。
@Garyy：
元数据服务器和监视器必须可以尽快地提供它们的数据，所以他们应该有足够的内存，至少每进程 1GB 。OSD 的日常运行不需要那么多内存（如每进程 500MB ）差不多了；然而在恢复期间它们占用内存比较大（如每进程每 TB 数据需要约 1GB 内存）。通常内存越多越好。
6、Ceph在激活OSD的时候提示没有权限？
【问题描述】KVM虚拟机，按照手册进行部署的，前面没有提示错误，最后激活OSD的时候提示没有权限。到OSD0，OSD1两台机器的/var/local/osd0和/var/local/osd1目录下看了一下，已经有文件存在了。不知道是哪的权限出了问题！还是说python2.7的问题？
@吕作令：
查看下ceph用户对于/var/local/osd0 /osd1 有没有用户权限， 可chown 下权限在尝试
@Garyy：
可以把具体的命令行贴出来看下，一般这种问题肯定是权限设置没有设置好导致的。
7、如何对Ceph集群进行配置，同时运行多个mds服务？
@Garyy：
cephfs多mds默认是动态负载均衡的，为了负载文件系统请求到多个mds。cephfs会根据每个mds计算一个热点值，热点高的mds缓存中的目录会往热点低的mds迁移，缓存中的目录在迁移的过程中是被锁定的，应用层的IO不能访问正在迁移的目录或文件，会导致部分IO访问中断几秒。于是用户就感觉卡了。
有2种方案，两种方案是独立使用的。
一，使用静态负载均衡，我们把业务绑定到mds，每次来业务我们根据mds性能监控报表，把业务绑定到负载低的mds上去，也叫手动负载均衡。操作过程如下：
1，把业务的根目录pin到mds上。
假设给用户a分配了目录/A ，用户b分配了目录/B，用户c分配了目录/C。那么我们把a用户分配到mds0，把b用户分配到mds1，把c用户分配到mds2。
setfattr -n ceph.dir.pin -v 0 /A
setfattr -n ceph.dir.pin -v 1 /B
setfattr -n ceph.dir.pin -v 2 /C
2, 设置cephfs的mds不迁移
只需要设置cephfs的mds不迁移，就能让子目录不迁移。
打开/etc/ceph/ceph.conf文件配置
mds_bal_min_rebalance=1000
每个mds都会产生一个热点值，这个热点值除以集群的总热点，然后和mds_bal_min_rebalance比较，超过mds_bal_min_rebalance就会迁移，但mds的热点值经过计算后怎么都不会超过1000的，所以只要配置mds_bal_min_rebalance=1000，多MDS之间就不会相互迁移缓存目录（不会产生负载均衡），既然不迁移，子目录就会跟着父母走，/A/AA会跟着父目录/A绑定到mds0上，而/A/AA/AAA会跟着父目录/A/AA绑定到mds0上。所以只要绑定了业务的根目录，并且设置了mds_bal_min_rebalance=1000，用户目录就被固定到了mds上。多个用户可以绑定到同一个mds上。
注意：只要使用这种模式，一定要绑定所有业务到mds上，否则业务会被默认分配到mds0上，造成mds0超载。
二，使用动态负载均衡。
依然采用默认的动态负载均衡，但是把迁移敏感度调小，让多mds之间迁移的粒度变小，而不是一下子迁移整个大目录，导致卡了很长时间。目录迁移的速度变快了，访问目录延迟的时间可以忽略不计。
1, 使多mds之间迁移粒度变小
mds_max_export_size = 20971520
2, 使mds之间热度的检测频繁变迟钝（根据场景适当调整）
mds_bal_interval = 10
mds_bal_sample_interval = 3.000000
这样既可以使用动态负载，也能避免负载均衡时候数据迁移导致的IO夯死。
8、Ceph在Windows下安装和在Linux安装有什么区别？
【问题描述】ceph-deploy install ceph-client这个命令在windows下安装的ceph能用吗？
@吕作令：
查询Ceph社区 （https://docs.ceph.com/） 目前ceph-deploy 仅支持；
Debian/Ubuntu
RHEL/CentOS
openSUSE
对于windows 还没有相关支持
@Garyy：
同上，一般集群都是采用Linux系统，安装部署会有专门的os版本；客户端一般采用普通windows或者Linux。
9、Ceph集群出现了故障，如何确切知道影响到了哪些文件？
【问题描述】Ceph向外提供文件系统，客户端mount到本地使用。如果集群健康状态不正常（比如某些对象丢失），此时如何知道哪些文件可用呢？
@Garyy：
Ceph同时提供对象存储、块存储、文件存储三种接口，但本质上其实是对象存储，也就是说一个rbd image实际上包含了多个对象（默认情况下是image_size/4M）。此处以块存储（RBD）为例进行演示，因为三种接口最终存储文件的操作单元都是对象，所以其他接口的方法类似：
前提：在bloc接口下有一个池：pool1,创建另一个volume（rbd image）：vol1。
因为这个vol1里其实包含了很多object，我们首先要查找object的位置：
1.查找volume(rbd image)的指纹信息
[root@controller-1 ~]#rbd info pool1/vol1
2.根据指纹找到这个volume的object
rados -p pool1 ls|grep bd85d5ffe883b
3.再根据object查找具体的存储位置
[root@controller-1 ~]# ceph osd map pool1 rbd_data.bd85d5ffe883b.00000000000004a7
进入到如下目录/Ceph/Data/Osd/osd-scsi-35000cca25e48d2e0/current，即可找到最终的存放文件夹5.1f_head
10、OpenStack 后端存储构建Ceph集群为什么不建议和RAID搭配使用？
【问题描述】在红帽官网文档看到说构建Ceph存储集群时，建议不要与RAID混合使用，这是什么原因？
@吕作令：
Ceph 和 RAID 不建议混合使用。
分布式存储已经做到了多副本的安全冗余机制。乃至1-6副本。Ceph已经解决了数据冗余的问题。不需要在做RAID，做RAID后反而增加了运维难度，若RAID在出现问题时，数据做重平衡过程中也会影响ceph 存储集群。
@Garyy：
分布式存储本来就具有数据冗余和修复功能。如果在单个节点上做RAID，当出现故障的时候，你可能要离线rebuild RAID。但不做RAID的话，换个硬盘就自动在线恢复了，业务完全不中断。
11、有哪些工具可以用来测试 Ceph 分布式文件系统的性能？
【问题描述】在 OSC 内部搭建了一套 Ceph 分布式文件系统，共 3 个节点。想对这个文件系统进行性能方面的测试，大家有什么好推荐呢？
@吕作令：
可以通过性能测试工具进行文件系统测试
如 VDBENCH、FIO 等
@Garyy：
比较常用的有fio，iozone，iometer。对于对象存储可以使用cosbench进行测试。
答疑专家：Garyy 某保险 系统工程师其他分享者：李静 XSKY 软件架构设计师；qsg0720 深圳杉岩 CTO；潇洒D鱼 XSKY 星辰天合 业务咨询顾问；zhisong NEU 研究学者；吕作令 XSKY 资深解决方案专家；Hongke 灵犀联云 软件开发工程师；冰河_C 北京东软 存储工程师如有任何问题，可点击文末阅读原文，到社区提问 觉得本文有用，请转发或点击“在看”，让更多同行看到
资料/文章推荐：
点击阅读原文关注社区 “分布式存储”技术主题 ，将会不断更新优质资料、文章，您也可以前往提出疑难问题，与同行切磋交流。地址：http://www.talkwithtrend.com/Topic/23951
下载 twt 社区客户端 APP
与更多同行在一起
高手随时解答你的疑难问题
轻松订阅各领域技术主题
浏览下载最新文章资料
长按识别二维码即可下载
或到应用商店搜索“twt”
*本公众号所发布内容仅代表作者观点，不代表社区立场